SE-Specification

Software Requirements Specification

• Is a document used to specify the users' requirements
• Is also called the system requirements specification
• Contains detailed descriptions of the system's functions, services, and operational constraints.
• Written by developers for developers
• Defines what should be implemented
• Can be written using natural language, structured natural language, diagrams, tables, or formal language (mathematics).
• Requirements should be specified quantitatively rather than qualitatively
• Guidelines for writing specifications include consistency in format, language, and content, ensuring readability, avoiding jargon, highlighting key parts, and using tables and diagrams
• The SRS should not include information such as cost, delivery schedules, reporting procedures, software development methods, quality assurance, validation and verification criteria, or acceptance procedures

What are UML diagrams used for?

• UML is the most popular diagrammatic notation used for object-oriented development
• They are used to support Object-Oriented Software Development from Object-Oriented Analysis (Requirements Specification) through Object-Oriented Programming (Implementation)
• They are used to analyze and specify software requirements
• They are used to create system models from different perspectives, including the environment, behavior flow, and structure of the system

Why is the software requirements specification important?

• It is a fundamental activity for understanding and defining system services and identifying constraints.
• It defines what should be implemented by providing detailed descriptions of the system's functions, services, and operational constraints.
• A clear specification helps avoid major problems like ambiguity, incompleteness, and inconsistency in requirements.
• Specifications can be used to generate test cases and test oracles.
• Capturing requirements is crucial for avoiding costly errors and helping projects meet their deadlines and budget.
• Writing documentation, which includes the SRS, is considered important in professional practice.

What are the main problems in software requirements? How to avoid these problems?

• Main Problems in Software Requirements:
  • Impreciseness, which includes:
    • Ambiguity: Requirements can be interpreted in different ways by different people.
    • Incompleteness: Some necessary information might be missing.
    • Inconsistency: Some descriptions might conflict with each other.
• Problems with Domain Requirements:
  • Lack of common background between customers and developers.
  • Confusion with functional requirements.
  • Professional differences ("worlds apart") between customers and developers.
  • If not satisfied, the system may be unworkable.
• Difficulty specifying and verifying some Non-Functional Requirements, such as "ease of use".
• Potential Conflicts between Non-Functional Requirements, like time (performance) and space (memory usage).

How to Avoid These Problems:

• Write a Software Requirements Specification (SRS), which is a detailed document defining what should be implemented.
• Ensure Consistency in the specification's format, language, and content. Be as precise as possible in content.
• Make the Specification Readable by avoiding jargon, understanding different backgrounds, highlighting key parts, using references, and employing tables and diagrams.
• Specify Requirements Quantitatively rather than qualitatively (e.g., "response time within 0.1 second" instead of "fast response time").
• Thoroughly Understand and Define System Services and Identify Constraints as a fundamental activity in the software development lifecycle.
• Do Not Include Information Not Belonging in the SRS, such as cost, delivery schedules, development methods, or acceptance procedures.
• A clear and consistent specification helps avoid ambiguity, incompleteness, and inconsistency.
• Specifications written in defined notation can be used to generate test cases and test oracles, implying precision helps verification.

Why do we need to generate models for requirements?

• Models are used to describe system requirements from different perspectives, including the environment, behavior flow, and structure of the system.
• They are a method for specifying requirements, using diagrams and graphical notation alongside other forms like natural language and tables.
• Generating models is part of analyzing requirements and the fundamental activity of understanding and defining system services and identifying constraints.
• Models help refine requirements and provide detailed descriptions.
• They are needed for validation, helping to ensure the system meets customer expectations by showing externally visible behavior from the user's point of view.
• Models serve as the basis for subsequent system design activities, translating the requirements into design structures.
• They help identify key system elements such as actors, use cases, objects, attributes, operations, and data transformations.

System Models

• System models are used to describe
  • the environment of the system
    • Context model
    • Use case diagram
  • the behavior flow of the system
    • State machine model
    • Data-flow model
  • the structure of the system
    • Data model
    • Object model

Environment Models

Context model

• Context model includes
  • Environment – includes all the parts of the system related to what we want to model
  • Boundary - separates out parts of the environment we want to model
• Many factors can affect the boundary of the model
  • Technical factors
  • Non-technical factors

Use Case Diagram

• A use case diagram

  • Describes the systems’ functionalities from a user’s (or other systems’) point of view
  • Shows the externally visible behavior of the system
  • Is in the first step of requirements specification

• A use case diagram contains

  • Actors
    • The role of the users that can play when interacting with the system
  • Use cases
    • Tasks (transactions) that the system can perform when users use the system

• The actors and use cases must be determined (决定) by consulting（磋商）with the clients (客户)

• Use case should focus on the goal rather than the process

• Good use cases should

  • Be observable – Focus on the basics

• Factors to consider when use case prioritizing

  • Support major business process
  • Architectural significance
  • Use of new technologies
  • Needs of substantial research efforts
  • Great improvement in efficiency

• Use case Scenario

  • A concrete sequence of events.
  • Occurs during one particular execution path in a user case
  • For every use case, there is a scenario that can describe the possible interactions between the user and the system for this use case.

• Basic scenario

  • Normal sequence of events
  • Achieve the main goal of the use case with no problem, no interruption

• Alternative scenario

  • Something goes wrong
  • Main goal cannot be finished
  • Normal case cannot be finished

• Example: Scenario for books

  • 

• A use case can be described in a natural language text containing abstract information (Initial description) or refined details (concrete information)

  • Initial Description
    • Name of the use case
    • Participating (参与) actors
    • Description
  • Concrete Description
    • Name of the use case
    • Use case ID
    • Participating（参与）actors
    • Entry conditions
    • Scenario
    • Priority
    • Exit Conditions
    • Quality requirements
    • Source

• Relationships in Use Case Diagrams

  • Between actors and use cases
    • Communication relationships
  • Between use cases
    • Include relationships
      • When use case A includes use case B, it means that use case B must be implemented in use case A.
      • For example, if a user must login to use the use case A, then A includes the use case login.
      • 
    • Extend relationships
      • For two use cases A and B, when B is optional to A.
      • If B is added into A to strengthen A, then B is an extension of A.
      • 
      • 
    • Inheritance relationships
      • For two use cases A and B, if A the generalization of B, and B is a specialization of A, then they have inheritance relationships.
      • Usually in this case, there are several ways to offer the same function.
      • 

Behavior Models

• Describe overall function of the system
  • State machine model (Finite State Machine)
    • Event-driven，e.g. embedded systems
  • Data flow models
    • Data-driven, e.g. information systems

State Machine Model

• State Machine Model

  • Has state transition (转换) diagrams
  • Also called state transition diagrams, finite state machine
  • Indicates how the system behaves as a consequence of external events
  • Describe the scenario in a diagram

• Elements in a State Machine Diagram

  • State
    • a mode of behavior
    • last for a period (period cannot be ignored)
  • Event
    • Causes the transition from a state to another state
  • Action
    • The behavior that the system reacts to an event
  • Condition
    • A condition for state transition when event happens

• Whether a behavior is a state or an event or an action depends on the real systems.

Data-Flow Model

• Indicates how data are transformed as they move through the system

• Depicts the functions that transform the data flow

• Explains to the systems users what is going on in the system (abstract)

• Helps designers to design the system architectures (detailed).

• Structured analysis method

  • Data-flow Diagrams (System Analysis)
  • Structured Modular Design (System Design)

• Widely used before the OO method

• 

Object-Oriented Technology

Object-Oriented Development

• A popular software development method
• Develop reusable systems
• The concept started in 1968
• Based on the use of single object

Objects & Classes

• Object

  • An entity (实体)
  • Physical: a chair, a desk, a person
  • Logical: a list, a stack, a rectangle
  • Feature
    • Can be described, e.g. shape, length
    • Can be created and destroyed

• Class

  • Normal meaning: A set of entities with similar attributes
  • Feature
    • Abstraction（抽象）
      • Focusing on the essential aspects (attributes under consideration) of an entity and ignoring its accidental (非主要的) properties.
      • Make some decision as late as possible
      • Avoid to make decisions on the design and implementation decisions before the problems are understood
    • Encapsulation（封装）Information Hiding
      • The attributes and operations of a class are hidden from outside world
      • Separate the external aspects of an object, which are accessible to other objects.
      • Reduce the affection of the changes
      • Facilitate component reuse
      • Simplify the interfaces
    • Inheritance（继承）
      • Super-class and sub-class
      • Sub-class include the attributes in the super-class with some added or specialized features
      • It is the key feature of OO
      • The implementation in the super-class can be reused
      • The common changes to all the sub-classes can be implemented in the super-class
      • A sub-class can have several super-classes.
    • Polymorphism（多态性）
      • Reduce the cost that is needed to extend the system
      • Allow a set of different implementations (semantic meanings）
      • similar operations to have the same name.
      • 

• OO Object-Oriented :Object + Classification + Inheritance + Communication

  • A description that encapsulates （封装）the data and procedural abstractions (抽象）that are required to describe the content and behavior of some real world entities
  • A generalized description that describes a collection of similar objects.

• OO in one sentence:

  • keep it DRY, keep it shy and tell the other guy
  • DRY: Do not Repeat Yourself
  • Shy: Should not reveal the information about itself unless really necessary
  • Tell the other guy: Send a message rather than a function call.

What are the features of a class?

• Abstraction
• Encapsulation
• Inheritance
• Polymorphism